摘要：《寻味奇旅》开发日志#2-记录一次Unity中的编辑器工具开发经历,为Unity开发蓝图系统 unityoculus 开发
⚠️ 未经作者授权 禁止转载
站内游戏链接：寻味奇旅 | 机核 GCORES （Demo即将上线）
概述
说到蓝图，第一个想到的 天然是UE中的蓝图 体系。UE的蓝图 体系对于开发而言真的及其的高效， 由于它具有极高的可读性。对于一个复杂的产品工程而言，其代码量很可能大的夸张。而游戏可以说是最复杂的软件产品形式了。后期面对着几十万行的代码真的 无从开始。在多人协同开发或者后期代码量大到你自己都忘了项目的结构的时候，你打开一张整理归纳好的蓝图，瞬间就可以及其清晰的 领会到功能的整体框架， 接着你再去关注你期望关注的细节，深入到某一块逻辑或者某一个具体的节点背后。 并且，蓝图对于具有复杂 情形的游戏角色或敌人来讲，也是其逻辑管理和设计模式优的一种极大的提升。在过去的游戏开发 经过中，我一开始只给敌人使用 情形机，后来才逐渐 觉悟到了 情形机不仅仅可以用于AI，它是一种设计模式，可以用于所有需要 情形管理的 物品，包括整个游戏的 情形，UI等等，都可以用到这种设计 思索。而AI，在有需求的情况下，它值得更好的更复杂的（行为树、GOAP、ML等）。后来我写的是代码上的F （就是逻辑上是F ，但没有可视化的节点图），这样已经可以做到非常好的逻辑控制了， 然而为了统一F 的调用接口等 难题，每个新 情形我都有单独做代码创建， 接着接入 情形机等等的，搞得我很繁琐。其次如果一个 情形内的逻辑太复杂了，这个 情形内的代码依然不太具备可读性。这也就是 何故我需要一个蓝图 体系了。
何故不用Unity的Visual Scripting
首先最简单的第一个 缘故，我喜欢写引擎工具（bushi）。其实用过UE的蓝图再对比Unity的Visual Scripting就会知道，UE的蓝图相对而言是高度概括化的，粗颗粒度的，功能封装的。当然，UE也可以做到及其细致的颗粒度，但实际上你会发现，像是人物移动这种 事务，只需要调用一个节点就完成了。而在Unity中想要效果足够好，光是人物移动的代码可能就要两三百行不止（兼容可移动平台，上下坡，跨越楼梯，地面判断等），同样的复杂逻辑在Visual Scripting中实现起来几乎就是灾难。另外就是UE的惯用开发流程是将复杂的、高度复用的、性能敏感的逻辑，利用C++编写再封装成单一节点。这样策划在配置实现逻辑的时候可以非常的高效，且游戏性能表现可以得到保证。再者是Visual Scripting高度依赖于C的反射运行，且运行时相当于解释性语言，这样C这种本就是半编译性语言的优势都完全丧失了，性能不占优，无法满足我们项目可能同频四五十个复杂逻辑调用的对象同时存在的性能要求。虽然Visual Scripting也支持封装C代码为一个节点，但其从底层结构上又不满足我对于不同的蓝图形式的要求（比如项目中我实现了F 图结构，类UE中Actor的蓝图结构，以及技能蓝图结构SkillGraph），也无法足够的简化让我们团队没有编程背景的策划也可以上手改逻辑。 因此我正好借此机会开发自定义的蓝图工具。只造必要的轮子
开发编辑器工具的 思索 与 策划的 思索是有共同之处的，首先就是明确核心目的。开发蓝图 体系本身需要解决的 难题是：- 杰出健壮的代码逻辑管理
- 方便战斗策划配置玩家&敌人单位逻辑
- 方便关卡策划配置机关逻辑
- 优化策划用户体验，满足游戏功能需要
因此我们针对这个蓝图工具，需要其达成的功能如下：- 不要为游戏的性能表现埋坑，前期就要做好压力测试
- 在满足UX需求的前提下，尽可能的不要自己重复造轮子
- 方便策划调试与修改
同时 由于我自己是我们项目的战斗策划，主要负责了角色3C+所有技能的设计+小怪和Boss的设计，以及战斗与烹饪 体系的数值平衡 职业。 因此整个蓝图工具开发的 经过，我自己作为开发者和用户一起在同步优化这个工具。蓝图工具底层构建
蓝图 体系本身可以分为三个大部分：数据存储 / 编辑工具 / 运行时逻辑。针对编辑工具这一块，其实我个人感觉Unity的ShaderGraph的用户体验是非常不错的，完全满足我们的需要。 并且经过Research，Unity的Shader Graph是基于Unity自己的GraphView开发的，这个GraphView就是我们需要的节点图底层。最终我找到了这个非常棒的开源库：alelievr/NodeGraphProcessor: Node graph editor framework focused on data processing using Unity UIElements and C 4.6 这 一个基于GraphView开发的可以自定义节点的蓝图编辑工具 + 数据存储工具。其基于Unity Scriptable Object来进行数据存储，这就需要我们非常小心的管理序列化。但Unity Scriptable Object的优势就是可以方便我们对Project中的各种资源进行引用， 并且搭配Odin的话还可以实现将System.Type也序列化的神奇功能。这个插件的核心数据结构如下：
BaseGraph承载BaseNode和Parameter，Parameter作为外部引用或者全局变量，BaseNode则包含具体的逻辑，Edge则表达了各个Node之间的连接关系。这 一个非常标准的蓝图结构。这样我们可以直接拓展BaseGraph，实现我自己期望的F Graph，Action Graph(类UE的Actor Graph)，Skill Graph。针对各类复杂逻辑，也可以直接拓展BaseNode即可。但这个插件存在着一个 难题，它的BaseGraph除了数据存储逻辑以外，还包含了运行时逻辑， 并且插件本身不会实例化这个BaseGraph，而是直接调用它，完全基于BaseGraph自身的来进行运行时数据的存储，逻辑的处理。这是非常不符合我的数据与逻辑分离的设计 思索的，像是目前我项目中的所有配置文件，全部遵从的是这个逻辑，要产生任何的运行时数据时，全部需要一个专门的脚本来承载，对待无论是Scriptable Object还是自己的Json等配置文件，应当全部当作这些数据是只读的。它这样的运行逻辑会带来的最首要的 难题，就是蓝图无法复用。同一张蓝图在Unity的内存中只存在一份，假设我有30个敌人，他们同时调用这同一张蓝图。每个敌人抢着修改同一份蓝图里的参数，到 最后就完全乱套了。另外它在Editor上也有一些 难题，譬如ExposedParameter按理说应该是写入全局参数的地方，但却不知为何，安装后就被Unity的序列化为只读的，而且我尝试了许多 技巧都修不好（有点难绷说实话
